1. Field of the Invention
This invention relates generally to wireless devices and voice over Internet Protocol (VoIP) technologies. More particularly, it relates to the provision of 911 services for VoIP users to a Public Safety Answering Point (PSAP).
2. Background of the Related Art
The E911 industry is challenged with being able to automatically deliver location information to the Public Safety Answering Points (PSAPs) for Voice Over Internet Protocol (VoIP) devices.
FIG. 3 shows a conventional E911 VoIP scenario.
In particular, as shown in FIG. 3, a VoIP carrier 100 includes a call server 202 and an Emergency Services Gateway (ESGW) 204.
A service bureau 120 includes a network location information server (LIS) 206, a Session Initiated Protocol (SIP) server (redirect) 208, and a VoIP positioning center (VPC) 210. Also included in the service bureau 120 is an Emergency Services Zone (ESZ) route database (DB) 220, and a validation database (DB) 230.
Also within the network are the Public Switched Telephone Network (PSTN) 130, a selective router 140, a Public Safety Answering Point (PSAP) 180, an Automatic Location Identification (ALI) database 190, a Master Street Address Guide (MSAG) 195, an Internet Protocol (IP) phone 150, a provisioning system 160, and a local Location Information Server (LIS) 170.
FIG. 4 shows exemplary call flow for the conventional E911 VoIP scenario shown in FIG. 3.
In particular, as shown in step 1 of FIG. 4, a caller on the IP phone 150 dials 9-1-1; and the call proceeds to the VoIP call server 202.
In step 2, the VoIP call server 202 sends a Session Initiated Protocol: uniform Resource Identifier (SIP:URI) to the SIP Server (redirect) 208.
In step 3, the SIP Server 208 queries the VoIP Positioning Center (VPC) 210 for the Emergency Services Routing Number (ESRN) and the Emergency Services Query Key (ESQK).
In step 4, the VoIP Positioning Center (VPC) 210, via the SIP Server 208, returns the ESRN & ESQK to the VoIP Carrier 100.
In step 5, the call server 202 uses the returned ESRN to route the wireless 911 call to the Emergency Services Gateway (ESGW) 204.
In step 6, the Emergency Services Gateway (ESGW) 204 routes the wireless 911 call to the selective router 140.
In step 7, the wireless 911 call is sent to the Public Safety Answering Point (PSAP) with the ESQK.
In step 8, the Public Safety Answering Point (PSAP) queries the Automatic Location Identification (ALI) database 190 using the ESQK.
In step 9, the Automatic Location Identification (ALI) database 190 queries the VoIP Positioning Center (VPC) 210 with the ESQK.
In step 10, the Service Bureau 120 matches the ESQK and returns location information.
Provision of an acceptable location for a VoIP device (particularly for a mobile VoIP device) presents a number of challenges, not the least of which is Metro Street Address Guide (MSAG) validation of a location for a VoIP E911 caller.
In particular, current Public Safety infrastructure is heavily wedded to wireline interfaces and to the notion of every E911 caller having a street address—not simply to the notion that latitude/longitude coordinates is more amenable to todays mobile phone culture. The entire conventional call scenario depicted in FIG. 4 presumes that a database record exists that identifies the location of the customer and that exists as an MSAG-validated address. In reality, this is not necessarily the case. Nevertheless, current PSAP architectures have entire response procedures built around street addresses only, and use the street address as a key to a table for looking up the appropriate emergency response. Accordingly, the bottom line is that conventional PSAPs require that location information be MSAG validated to guarantee that the PSAP database lookup will not fail.
Fundamentally, MSAG is a legacy requirement from PSAPs that did (and some still do) have “dumb” terminals that receive the call and display the address information to the call taker. In early PSAP systems, information delivery was slow and cumbersome, so the industry worked on developing a set of abbreviations that would allow an address to fit into about 20 characters.
Wireless Phase I requirements defined by NENA provide E9-1-1 for VoIP using PSAP administrative lines. Wireless Phase II requirements defined by NENA provide E9-1-1 for VoIP across traditional 9-1-1 channels. In wireless Phase II, the location of the caller is dynamically extracted from the network. This results in a latitude/longitude (lat/lon) coordinate being provided to the PSAP. Those PSAPs which have been upgraded to handle lat/lon receive the information and display it on a screen driven by a Graphical Information System (GIS), i.e., they see a map with a “caller is here” flag or dot. Such a conventional system is suitable in PSAPs which have upgraded to handle these Wireless Phase II calls (currently somewhere north of 40% of all PSAPS). However, older PSAPs still need address information, and they expect to receive an MSAG-validated address. So, for wireless, the address is given as the center of the cell site/sector which is serving the caller. Not very precise, but good enough to get emergency services in a vicinity of a wireless caller.
With Voice Over Internet Protocol (VoIP) usage, it is desirable to apply a similar model as is done in wireless. In other words, it is desirable that location information be dynamically extracted from the network, and presented to the PSAP. Unfortunately, VoIP systems, being based on the ubiquitous Internet, do not always have the luxury of a cell site/sector overlay to fall back on. In other words, a VoIP caller can make a 911 call from anywhere in the country, but there is no credible database of MSAG-validated addresses for the Internet routers to deliver the 911 call.
There is a need for a way for VoIP users to have the best of both worlds-provision of location information in latitude/longitude (lat/lon) coordinates to a PSAP, while at the same time providing the PSAP with an MSAG validated location.